Graphics application program interfaces (APIs) have been instrumental in allowing applications to be written to a standard interface and to be run on multiple platforms, i.e. operating systems. Examples of such graphics API's include the Open Graphics Library (OpenGL®) and Direct3D™. OpenGL® is the computer industry's standard graphics API for defining 2-D and 3-D graphic images. With OpenGL®, an application can create the same effects in any operating system using any OpenGL®-adhering graphics adapter. OpenGL® specifies a set of commands or immediately executed functions. Each command directs a drawing action or causes special effects.
Thus, in any computer system which supports the OpenGL® standard, the operating system(s) and application software programs can make calls according to the standard, without knowing any specifics regarding the hardware configuration of the system. This is accomplished by providing a complete library of low-level graphics manipulation commands, which can be used to implement graphics operations.
A significant benefit is afforded by providing a predefined set of commands in graphics API's such as OpenGL®. By restricting the allowable operations, such commands can be highly optimized in the driver and hardware implementing the graphics API.
While many benefits have been derived from the use of graphics API's, there unfortunately are still numerous drawbacks and shortcomings in the many available graphics API's which require improvement.
By way of example, most APIs introduce “breaks,” or pauses, in processing among components of a graphics pipeline. One particular situation where this may arise is in the context of occlusion culling APIs. Occlusion culling APIs like the HP_occlusion_test extension define a mechanism whereby an application can query the visibility of an object, where “visible” means that at least one fragment passes the depth and stencil tests.
APIs like the HP_occlusion_test extension employ a simple “stop-and-wait” model for handling multiple occlusion queries. The application begins an occlusion test and ends it. Subsequently, at some later point, the application asks for the result, at which point the driver must stop and wait until the result from that test is returned before the application can begin the next test. This is a very simple model, but the resulting performance is mediocre when an application performs many queries, because it eliminates most of the opportunities for parallelism between a central processing unit and graphics hardware.
There is thus a need to provide a graphics API that overcomes such problems in the context of occlusion testing.